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Les 


Introduction 


The "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)" [RFC4283] 
has proved to be a popular design tool for providing identifiers for 
mobile nodes during authentication procedures with Authentication, 
Authorization, and Accounting (AAA) protocols such as Diameter 
[RFC6733]. To date, only a single type of identifier has been 
specified, namely the Mobile Node (MN) NAI. Other types of 
identifiers are in common use and are even referenced in RFC 4283. 
In this document, we propose adding some basic identifier types that 
are defined in various telecommunications standards, including types 
for International Mobile Subscriber Identity (IMSI) [ThreeGPP-IDS], 
Packet - Temporary Mobile Subscriber Identity (P-TMSI) 
[ThreeGPP-IDS], International Mobile station Equipment Identities 
(IMEI) [ThreeGPP-IDS], and Globally Unique Temporary UE Identity 
(GUTI) [ThreeGPP-IDS]. In addition, we specify the IPv6é address 
itself and IEEE MAC-layer addresses as Mobile Node identifiers. 
Defining identifiers that are tied to the physical elements of the 
device (e.g., the MAC address) help in deployment of Mobile IP 
because, in many cases, such identifiers are the most natural means 
for uniquely identifying the device and will avoid additional lookup 
steps that might be needed if other identifiers were used. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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3. New Mobile Node Identifier Types 


July 2018 


The following types of identifiers are commonly used to identify 


mobile nodes. For each type, 
details on the format of the type of identifier. 


IPv6 Address 


IMSI 
Identity 


P-TMSI 


Identity 


EUI-48 
Address 


EUI-64 
Address 


| 
| 
| 
| 
| 
| GUTI 
| 
| 
| 
| 
| 
| 


+ 


International Mobile Subscriber 


Packet - Temporary Mobile 


Subscriber Identity 


Globally Unique Temporary UE 


48-Bit Extended Unique Identifier 


64-Bit Extended Unique Identifier 


DHCPv6 Unique Identifier 


+ 
| 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 

+ 


references are provided with full 


SS Se a ee + 
Reference | 


[RFC4291] 


[ThreeGPP-IDS] 


[ThreeGPP-IDS] 


[IEEE802] 


| 

| 

| 

| 

| 
[ThreeGPP-IDS] | 
| 

| 
[IEEE802] | 
| 

| 

| 


[RFC3315] 


Table 1: Mobile Node Identifier Description 


4. Descriptions of MN Identifier Types 


This section provides descriptions for the various MN identifier 


types. 


4.1. Description of the IPv6 Address Type 


The IPv6 address [RFC4291] 


addresses, link-local addresses, 
MUST NOT be used. IPv6 Unique Local Addresses 


is encoded as a 16-octet string containing 
a full IPv6é address that has been assigned to the mobile node. The 
IPv6 address MUST be a unicast routable IPv6 address. Multicast 


and the unspecified IPv6é address 
(ULAsS) MAY be used as 


long as any security operations making use of the ULA also take into 
account the domain in which the ULA is guaranteed to be unique. 
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4.2. Description of the IMSI MN Identifier Type 


The International Mobile Subscriber Identity (IMSI) [ThreeGPP-IDS] is 


at most 15 decimal digits (i.e., digits from 0 through 9). The IMSI 
MUST be encoded as a string of octets in network order (i.e., high to 
low for all digits), where each digit occupies 4 bits. If needed for 


full octet size, the last digit MUST be padded with Oxf. For 
instance, an example IMSI 123456123456789 would be encoded as 
follows: 


0x12, 0x34, 0x56, 0x12, 0x34, 0x56, 0x78, Ox9f 
4.3. Description of the EUI-48 Address Type 


The IEEE EUI-48 address [IEEE802-GUIDELINES] is encoded as 6 octets 
containing the IEEE EUI-48 address. 


4.4. Description of the EUI-64 Address Type 


The IEEE EUI-64 address [IEEE802-GUIDELINES] is encoded as 8 octets 
containing the full IEEE EUI-64 address. 


4.5. Description of the DUID Type 


The DUID is the DHCPv6 Unique Identifier [RFC3315]. There are 
various types of DUIDs, which are distinguished by an initial two- 
octet type field. Clients and servers MUST treat DUIDS as opaque 
values and MUST only compare DUIDs for equality. 


5. Security Considerations 


This document does not introduce any security mechanisms and does not 
have any impact on existing security mechanisms. 


Mobile node identifiers such as those described in this document are 
considered to be private information. If used in the MN identifier 
extension as defined in [RFC4283], the packet including the MN 
identifier extension MUST be encrypted so that no personal 
information or trackable identifiers are inadvertently disclosed to 
passive observers. Operators can potentially apply IPsec 
Encapsulating Security Payload (ESP) [RFC4303] in transport mode with 
confidentiality and integrity protection for protecting the identity 
and location information in MIPv6 signaling messages. 


Some MN identifiers contain sensitive identifiers that, as used in 
protocols specified by other Standards Development Organizations 
(SDOs), are only used for signaling during initial network entry. In 
such protocols, subsequent exchanges then rely on a temporary 
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7. 


7. 


identifier allocated during the initial network entry. Managing the 
association between long-lived and temporary identifiers is outside 
the scope of this document. 


IANA Considerations 
The new mobile node identifier types defined in this document have 


been assigned values from the "Mobile Node Identifier Option 
Subtypes" registry. The following values have been registered. 


HoH SSSsH Sa SSssses = 4------------------------ + 
| Identifier Type | Identifier Type Number | 
fee SoS +------------------------ + 
| IPv6 Address | 2 | 
| IMSI | 33. | 
P-TMSI 4 
EUI-48 address 5 
| EUI-64 address | 6 
| GUTI l7 | 
| DUID | 8 | 
| Reserved | 9-15 
| Unassigned | 16-255 | 
POSS SSeS e Poa SSS oss Sel Sess =e + 


Table 2: New Mobile Node Identifier Types 


See Section 4 for additional information about the identifier types. 
The registration procedure is Standards Action [RFC8126]. The expert 
must ascertain that the identifier type allows unique identification 
of the mobile device; since all MN identifiers require encryption, 
there is no additional privacy exposure attendant to the use of new 
types. 
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Appendix A. RFID Types 


The material in this non-normative appendix was originally composed 
for inclusion in the main body of the specification but was moved 
into an appendix because there was insufficient support for 
allocating Radio Frequency Identification (RFID) types at the time. 
It was observed that RFID-based mobile devices may create privacy 
exposures unless confidentiality is assured for signaling. A 
specification for eliminating unauthorized RFID tracking based on 
Layer 2 addresses would be helpful. 


Much of the following text is due to contributions from Hakima 
Chaouchi. For an overview and some initial suggestions about using 
RFID with IPv6 on mobile devices, see [Using-RFID-IPv6]. 


In the context of Internet of Things (IoT) and Industry 4.0, vertical 
domain, efficient inventory, and tracking items are of major 
interest, and RFID technology is the identification technology in the 
hardware design of many such items. 


The "TRACK-IoT" project [TRACK-IoT] [RFID-framework] explored Mobile 
IPv6 as a mobility management protocol for RFID-based mobile devices. 


1. Passive RFID tags (that have no processing resources) need to be 
handled by the gateway (likely also the RFID reader), which is 
then the endpoint of the mobility protocol. It is also the point 
where the Change of Address (CoA) will be created based on some 
combination such as the RFID tag and the prefix of that gateway. 
The point here is to offer the possibility to passive RFID items 
to get an IPv6 address and take advantage of the mobility 
framework to follow the mobile device (passive tag on the item). 
One example scenario that has been proposed, which shows the need 
for mobility management of passive RFID items, would be pieces of 
art tagged with passive tags that need to be monitored while 
transported. 


2. Using active RFID tags (where the processing resource is 
available on the tag), the endpoint of the mobility protocol can 
be hosted directly on the RFID active tag, which is also called 
an identification sensor. A use case for active RFID tags 
includes traceability of cold food during mobility (transport). 
Also, mobility of cars equipped with active RFID tags that we 
already use for toll payment can be added with mobility 
management. 


One major effort to connect IETF efforts to EPCglobal (RFID 
standardization) led to the Object Name Service (ONS), which is the 
DNS version applied for RFID logical names and page information 
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retrieval. Attempts have been made to connect IPv6 on the address 
space to RFID identifier format. Other initiatives started working 
on gateways to map tag identifiers with IPv6 addresses and build 
Signaling protocols for the application level. For instance, 
tracking of mobile items equipped with a tag can be triggered 
remotely by a remote correspondent node until a visiting area where a 
mobile item equipped with an RFID tag is located. An RFID reader 
will be added with an IPv6-to-RFID tag translation. One option is to 
build a home IPv6 address of that tagged item by using the prefix of 
the home agent combined with the tag RFID identifier of the mobile 
item; as the tag ID is unique, the home IPv6 address of that item 
will be also unique. Then, the visiting RFID reader will compose the 
IPv6 care of address of the tagged mobile item by combining the 
prefix of the RFID reader with the tag ID of the item. MIPv6 can 
then normally provide the mobility management of that RFID-tagged 
item. A different, useful example of tagged items involves items of 
a factory that can be tracked while they are transported, especially 
for real-time localization and tracking of precious items transported 
without GPS. An automotive car manufacturer can assign IPv6 
addresses corresponding to RFID-tagged cars or mechanical car parts 
and build a tracking data set of the mobility not only of the cars, 
but also of the mechanical pieces. 


The Tag Data Standard promoted by Electronic Product Code (EPC) 
[EPC-Tag-Data] supports several encoding systems or schemes, which 
are commonly used in RFID applications, including the following: 

o RFID-GID (Global Identifier), 

o RFID-SGTIN (Serialized Global Trade Item Number), 

o RFID-SSCC (Serial Shipping Container Code), 

o RFID-SGLN (Serialized Global Location Number), 


o RFID-GRAI (Global Returnable Asset Identifier), 


o RFID-DOD (Department of Defense ID), and 


o RFID-GIAI (Global Individual Asset Identifier). 
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For each RFID scheme except GID, there are three representations: 


o a 64-bit binary representation (for example, SGLN-64), excluding 
GID, 


o a 96-bit binary representation (SGLN-96), and 
o a representation as a URI. 


The URI representation for the RFID is actually a URN. The EPC 
document has the following language: 


All categories of URIs are represented as Uniform Reference Names 
(URNs) as defined by [RFC2141], where the URN Namespace is epc. 


The following list includes the above RFID types. 
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Identifier 


RF ID-SSCC-64 
RF ID-SGLN-64 
RF ID-GRAI-64 
RF ID-DOD-64 
RF ID-GIAI-64 


ID-GID-96 
ID-SGTIN-96 


RF ID-SSCC-96 
RF ID-SGLN-96 
RF ID-GRAI-96 
RF ID-DOD-96 
RF ID-GIAI-96 
RFID-GID-URI 
RFID-SGTIN-URI 
RFID-SSCC-URI 
RFID-SGLN-URI 


RF ID-GRAI-URI 


RF ID-DOD-URI 


RFID-GIAI-URI 


Table 3: 
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64-bit Serialized Global Trade 
Item Number 

64-bit Serial Shipping 
Container Code 

64-bit Serialized Global 
Location Number 

64-bit Global Returnable Asset 
Identifier 

64-bit Department of Defense 
ID 

64-bit Global Individual Asset 
Identifier 

96-bit Global Identifier 
96-bit Serialized Global Trade 
Item Number 

96-bit Serial Shipping 
Container 

96-bit Serialized Global 
Location Number 

96-bit Global Returnable Asset 
Identifier 

96-bit Department of Defense 
ID 

96-bit Global Individual Asset 
Identifier 

Global Identifier represented 
as a URI 

Serialized Global Trade Item 
Number represented as a URI 
Serial Shipping Container Code 
represented as a URI 

Global Location Number 
represented as a URI 

Global Returnable Asset 
Identifier represented as a 
URI 

Department of Defense ID 
represented as a URI 

Global Individual Asset 
Identifier represented as a 
URI 


+ 
| 
| 

+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
+ 


[EPC-Tag-Data] 
[EPC-Tag-Data] 
[EPC-Tag-Data] 


[EPC-Tag-Data] 


[RF ID-DoD-spec] 


[EPC-Tag-Data] 


[EPC-Tag-Data] 
[EPC-Tag-Data] 


[EPC-Tag-Data] 


[EPC-Tag-Data] 


[EPC-Tag-Data] 


[RF ID-DoD-spec] 


[EPC-Tag-Data] 
[EPC-Tag-Data] 
[EPC-Tag-Data] 
[EPC-Tag-Data] 


[EPC-Tag-Data] 


[EPC-Tag-Data] 


[RF ID-DoD-spec] 


[EPC-Tag-Data] 
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A.1. Description of the RFID Types 


The material in this appendix has been either quoted or loosely 
adapted from [EPC-Tag-Data]. 


The General Identifier (GID) that is used with RFID is composed of 
three fields: General Manager Number, Object Class, and Serial 
Number. The General Manager Number identifies an organizational 
entity that is responsible for maintaining the numbers in subsequent 
fields. GID encodings include a fourth field, the header, to 
guarantee uniqueness in the namespace defined by EPC. 


Some of the RFID types depend on the Global Trade Item Number (GTIN) 
code defined in the EAN.UCC General Specifications [EANUCCGS]. A 
GTIN identifies a particular class of object, such as a particular 
kind of product or SKU. 


The EPC encoding scheme for SGTIN permits the direct embedding of 
EAN.UCC System standard GTIN and Serial Number codes on EPC tags. In 
all cases, the check digit is not encoded. Two encoding schemes are 
specified, SGTIN-64 (64 bits) and SGTIN-96 (96 bits). 


The Serial Shipping Container Code (SSCC) is defined by the EAN.UCC 
Specifications. Unlike the GTIN, the SSCC is already intended for 
assignment to individual objects and therefore does not require 
additional fields to serve as an EPC pure identity. Two encoding 
schemes are specified, SSCC-64 (64 bits) and SSCC-96 (96 bits). 


The Global Location Number (GLN) is defined by the EAN.UCC 
Specifications. A GLN can represent either a discrete, unique 
physical location such as a warehouse slot, or an aggregate physical 
location such as an entire warehouse. In addition, a GIN can 
represent a logical entity that performs a business function such as 
placing an order. The Serialized Global Location Number (SGLN) 
includes the Company Prefix, Location Reference, and Serial Number. 


The Global Returnable Asset Identifier (GRAI) is defined by the 
General EAN.UCC Specifications. Unlike the GTIN, the GRAI is already 
intended for assignment to individual objects and therefore does not 
require any additional fields to serve as an EPC pure identity. The 
GRAI includes the Company Prefix, Asset Type, and Serial Number. 


The Global Individual Asset Identifier (GIAI) is defined by the 
General EAN.UCC Specifications. Unlike the GTIN, the GIAI is already 
intended for assignment to individual objects and therefore does not 
require any additional fields to serve as an EPC pure identity. The 
GRAI includes the Company Prefix and Individual Asset Reference. 
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The DoD Construct identifier is defined by the United States 
Department of Defense (DoD). This tag data construct may be used to 
encode tags for shipping goods to the DoD by a supplier who has 
already been assigned a Commercial and Government Entity (CAGE) code. 


A.1.1. Description of the RFID-SGTIN-64 Type 


The RFID-SGTIN-64 is encoded as specified in [EPC-Tag-Data]. The 
SGTIN-64 includes five fields: Header, Filter Value (additional data 
that is used for fast filtering and preselection), Company Prefix 
Index, Item Reference, and Serial Number. Only a limited number of 
Company Prefixes can be represented in the 64-bit tag. 


A.1.2. Description of the RFID-SGTIN-96 Type 


The RFID-SGTIN-96 is encoded as specified in [EPC-Tag-Data]. The 
SGTIN-96 includes six fields: Header, Filter Value, Partition (an 
indication of where the subsequent Company Prefix and Item Reference 
numbers are divided), Company Prefix Index, Item Reference, and 
Serial Number. 


A.1.3. Description of the RFID-SSCC-64 Type 


The RFID-SSCC-64 is encoded as specified in [EPC-Tag-Data]. The 
SScC-64 includes four fields: Header, Filter Value, Company Prefix 
Index, and Serial Reference. Only a limited number of Company 
Prefixes can be represented in the 64-bit tag. 


A.1.4. Description of the RFID-SSCC-96 Type 
The RFID-SSCC-96 is encoded as specified in [EPC-Tag-Data]. The 
SSCC-96 includes six fields: Header, Filter Value, Partition, Company 
Prefix, and Serial Reference, as well as 24 bits that remain 
unallocated and must be zero. 


A.1.5. Description of the RFID-SGLN-64 Type 


The RFID-SGLN-64 type is encoded as specified in [EPC-Tag-Data]. The 
SGLN-64 includes five fields: Header, Filter Value, Company Prefix 
Index, Location Reference, and Serial Number. 


A.1.6. Description of the RFID-SGLN-96 Type 
The RFID-SGLN-96 type is encoded as specified in [EPC-Tag-Data]. The 


SGLN-96 includes six fields: Header, Filter Value, Partition, Company 
Prefix, Location Reference, and Serial Number. 
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A.1.7. Description of the RFID-GRAI-64 Type 


The RFID-GRAI-64 type is encoded as specified in [EPC-Tag-Data]. The 
GRAI-64 includes five fields: Header, Filter Value, Company Prefix 
Index, Asset Type, and Serial Number. 


A.1.8. Description of the RFID-GRAI-96 Type 


The RFID-GRAI-96 type is encoded as specified in [EPC-Tag-Data]. The 
GRAI-96 includes six fields: Header, Filter Value, Partition, Company 
Prefix, Asset Type, and Serial Number. 


A.1.9. Description of the RFID-GIAI-64 Type 


The RFID-GIAI-64 type is encoded as specified in [EPC-Tag-Data]. The 
GIAI-64 includes four fields: Header, Filter Value, Company Prefix 
Index, and Individual Asset Reference. 


A.1.10. Description of the RFID-GIAI-96 Type 


The RFID-GIAI-96 type is encoded as specified in [EPC-Tag-Data]. The 
GIAI-96 includes five fields: Header, Filter Value, Partition, 
Company Prefix, and Individual Asset Reference. 


A.1.11. Description of the RFID-DoD-64 Type 


The RFID-DoD-64 type is encoded as specified in [RFID-DoD-spec]. The 
DoD-64 type includes four fields: Header, Filter Value, Government 
Managed Identifier, and Serial Number. 


A.1.12. Description of the RFID-DoD-96 Type 


The RFID-DoD-96 type is encoded as specified in [RFID-DoD-spec]. The 
DoD-96 type includes four fields: Header, Filter Value, Government 
Managed Identifier, and Serial Number. 


A.1.13. Description of the RFID URI Types 


In some cases, it is desirable to encode in URI form a specific 
encoding of an RFID tag. For example, an application may prefer a 
URI representation for report preparation. Applications that wish to 
manipulate any additional data fields on tags may need some 
representation other than the pure identity forms. 


For this purpose, the fields as represented in previous sections are 


associated with specified fields in the various URI types. For 
instance, the URI may have fields such as CompanyPrefix, 
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ItemReference, or SerialNumber. For details and encoding specifics, 
consult [EPC-Tag-Data]. 
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